Businesses employ large scale data processing systems for storing and processing their business critical data. FIG. 1 shows in block diagram form relevant components of an exemplary data processing system 10. FIG. 1 and this background of the invention should not be considered prior art to the claims set forth below.
Data processing system 10 includes a host (e.g., server computer system) 12 coupled to data storage subsystems 16-20 via storage interconnect 22. Storage interconnect 22 may consist of several devices (e.g., routers, switches, etc.) for transmitting input/output (IO) transactions or other data between host 12 and data storage subsystems 16-20. For purposes of explanation, FIG. 1 shows one device 14 within storage interconnect 22 it being understood that the term storage interconnect should not be limited thereto.
Each of the data storage subsystems 16-20 includes several physical storage devices. For purposes of explanation, the physical storage devices of 16-20 take form in hard disks, it being understood that the term physical storage device should not be limited to hard disks. Data storage subsystems 16-20 may take different forms. For example, data storage system 16 may consist of “just a bunch of disks” (JBOD) connected to an array controller card. Data storage subsystem 18 may consist of an intelligent disk array. Data storage system 20 may consist of a block server appliance. For purposes of explanation, each of the data storage subsystems 16-20 will take form in a disk array.
As noted, each of the disk arrays 16-20 includes several hard disks. The hard disk is the most popular, permanent storage device currently used. A hard disk's total storage capacity is divided into many small chunks called physical memory blocks. For example, a 10 GB hard disk contains 20 million physical memory blocks, with each block able to hold 512 bytes of data. Any random physical memory block can be written to or read from in about the same amount of time, without having to first read from or write to other physical memory blocks. Once written, a physical memory block continues to hold data even after the hard disk is powered down.
Host node 12 includes an application 26 which is configured to generate IO transactions for accessing data in a logical data volume (more fully described below) in response to requests received from client computer systems (not shown) coupled to host 12. Host 12 also includes a storage manager 30 coupled to storage object description memory 40 and storage object specifications memory 50. FIG. 1 also shows that each of the devices 14-20 have their own storage managers each coupled to storage object description and storage object specification memories. Each of the storage managers may take form in software instructions executing on one or more processors. Volume Manager™ provided by VERITAS Software Corporation of Mountain View, Calif., is the exemplary storage manager, it being understood that the term storage manager should not be limited thereto.
Storage managers virtualize data storage. Storage virtualization is the technique of aggregating hard disks into one or more virtual disks that typically have better characteristics (e.g., higher storage capacity, greater effective data transfer rates, etc.) than individual hard disks. Hereinafter, virtual disks will be referred to as storage objects. Importantly, storage managers can also create storage objects by aggregating underlying storage objects.
Storage objects are abstractions and can be logically viewed as an array of logical memory blocks that store or are configured to store data. While it is said that a logical memory block stores or is configured to store data, in reality the data is stored in at least one physical memory block of a hard disk allocated directly or indirectly to the storage object. As will be described below, configuration maps or algorithms may be used to map logical memory blocks to physical memory blocks.
As noted, storage objects can themselves be aggregated to form higher level storage objects. Some storage objects (e.g., data volumes) are presented for direct or indirect access by an application such as application 26 executing on host 12. Application 26 can generate IO transactions to read data from or write data to logical memory blocks of a data volume not knowing that the data volume is an aggregation of underlying storage objects, which in turn may be aggregations of hard disks within disk arrays 16-20.
Storage objects are created by storage managers according to the requirements of specifications (also known as intents) provided thereto. Storage object specifications typically define how underlying storage objects or hard disks are to be aggregated. The more common forms of aggregation include concatenated storage, striped storage, mirrored storage, or RAID storage. Specifications may also define the type of underlying storage objects or hard disks to be aggregated. For example, a specification may define that three separate mirrored storage objects (as opposed to RAID storage objects) are to be aggregated to create a stripped storage object having three columns. As a further example, a specification may define that hard disks in separate disk arrays are to be aggregated to form mirrors of a mirrored storage object. A more complete discussion of how storage objects or hard disks can be aggregated can be found within Dilip M. Ranade [2002], “Shared Data Clusters,” Wiley Publishing, Inc., which is incorporated herein by reference in its entirety.
A storage object description is created for each storage object. In general, the storage object description relates the storage object to underlying storage objects or hard disks. The description may include a configuration map or algorithm that can be used to map (1) each logical memory block of the storage object to one or more logical blocks of one or more underlying storage objects, or (2) each logical memory block to one or more physical memory blocks. Storage managers 30-38 use configuration maps or algorithms to translate IO transactions that access one storage object into one or more IO transactions that access one or more underlying storage objects or hard disks. Consider for example, a two-way mirrored storage object O created by storage manager 32 from underlying hard disks d1 and d2 (not shown) of disk array 16. Storage object O consists of nmax logical memory blocks. Storage manager 32 creates a configuration map for storage object O and stores the configuration map into memory 42. The configuration map maps each logical block n of storage object O to physical blocks x and y in hard disks d1 and d2, respectively. When storage manager 32 receives an IO transaction to write data D to logical memory block 3 of storage object O, storage manager 32 accesses the configuration map for storage object O to learn that logical memory block 3 is mapped to, for example, physical memory blocks 565 and 7668 in hard disks d1 and d2, respectively. Storage manager 32 can then generate first and second IO transactions to write data D to blocks 565 and 7668 in hard disks d1 and d2, respectively.
Storage object descriptions typically include information that defines the properties of storage objects. For example, a storage object description may indicate that a corresponding stripped storage object has three columns each of which consists of an underlying mirrored storage object, or a storage object description may indicate that a corresponding mirrored storage object has two mirrors each of which is formed out of a separate hard disk. It is noted that storage object descriptions may include further information. For instance storage object descriptions may include information indicating that one storage object is a point-in-time copy of another storage object.
Storage managers 30-38 create storage objects according to specification requirements stored within specification memories 50-58, respectively. In conjunction with creating storage objects, storage managers 30-38 create and store storage object descriptions into storage object description memories 50-58, respectively. Moreover, descriptions of storage object properties are exported for consideration to other storage managers that seek to create new storage objects from existing underlying storage objects. It is noted that specifications can change for storage objects over time to reflect, for example, a change in storage strategy or goals. For example, a specification may be changed to accommodate a system administrator's desire to grow, evacuate, relocate, etc., a corresponding storage object. When specifications change, storage managers often change corresponding storage objects and produce new or modified storage object descriptions.
Storage managers don't communicate with each other when a storage object is modified, and this can lead to problems. To illustrate, presume that storage managers 32-36 create storage objects M1Example-M5Example. Storage objects M1Example and M4Example are created by storage manager 32 according to corresponding specifications in specifications memory 52. Storage objects M2Example and M5Example are created by storage manager 34 according to corresponding specifications in specifications memory 54. Storage object M3Example is created by storage manager 36 according to a corresponding specification in specification memory 56. Each of M1Example-M5Example is required by its corresponding specification to be formed by aggregating one or more hard disks contained within a single disk array. Presume that storage objects M1Example-M3Example are created from hard disks d1-d3, respectively, of disk arrays 16-20, respectively, and that storage object M4Example and M5Example are created formed from hard disks d4 and d5, respectively, of disk arrays 16 and 18, respectively. Storage object descriptions including configuration maps and storage object properties are created by storage managers 32-36 for storage objects M1Example-M5Example and are stored within storage object description memories 42-46. Further, the properties of storage objects M1Example-M5Example are provided to storage manager 38 in interconnect device 22 for consideration.
Presume now that storage manager 38 creates mirrored storage objects S1Example and S2Example according to specifications in specifications memory 58. Each of mirrored storage objects S1Example and S2Example is required to have two mirrors. Each mirror of S1Example is required to be formed out of one or more hard disks contained within a single disk array, and each mirror of S2Example is required to be formed out of one or more hard disks contained within a single disk array. Storage manager 38 creates mirrored storage object S1Example out of storage objects M1Example and M2Example since and the descriptive properties of these storage objects meets the specification requirements of S1Example, and storage manager 38 creates mirrored storage object S2Example out of storage objects M3Example and M4Example since and the descriptive properties of these storage objects meets the specification requirements of S2Example. Storage object descriptions including configuration maps and storage object properties are created by storage manager 38 for storage objects S1Example and S2Example and are stored within storage object description memory 48. Further, the properties of storage objects S1Example and S2Example are provided to storage manager 30 for consideration.
Lastly, presume a system administrator seeks to create a striped data volume VExample for access by application 26. A specification that defines striped data volume VExample is provided to memory 50 within host 12. This specification indicates that striped volume VExample should have two columns, each column consisting of a two-way mirrored storage object. Importantly, the specification for VExample requires the mirrors of each of the two-way mirrored storage objects to be formed from hard disks of separate disk arrays. Storage manager 30 in response to receiving the specification for VExample, reviews the properties of storage objects available to it including those of mirrored storage objects S1Example and S2Example provided by storage manager 38. Storage manager 30 learns that the properties of storage objects S1Example and S2Example fit the specification requirements for VExample. Accordingly, storage manager 30 aggregates mirrored storage objects S1Example and S2Example as the two columns for striped volume VExample. Storage manager 30 also creates and stores in memory 40 the corresponding description including the configuration map for VExample.
Now, presume a hardware or software failure renders hard disk d1 unusable, thus rendering storage object M1Example unusable. Storage manager 38 reacts to the unavailability storage object M1Example and reconfigures mirrored storage object S1Example by replacing M1Example with storage object M5Example provided by disk array 18. It is noted that replacing M1Example with storage object M5Example does not violate the specification requirements for S1Example that each of its mirrors be formed from one or more hard disks contained in a single disk array. Storage manager 30 of host 12, however, may be unaware that mirrored storage object S1Example has been reconfigured. The reconfiguration of mirrored storage object S1Example unfortunately violates the specification requirements for striped volume VExample since the specification for VExample requires each column of VExample to be formed out of a two-way mirrored storage object having mirrors formed out of hard disks in separate disk arrays.